KiWi - A Platform for Semantic Social Software

Semantic Wikis have demonstrated the power of combining Wikis with Semantic Web technology. The KiWi system goes beyond Semantic Wikis by providing a flexible and adaptable platform for building different kinds of Social Semantic Software, powered by Semantic Web technology. This article describes the main functionalities and components of the KiWi system with respect to the user interface and to the system architecture. A particular focus is given to what we call “content versatility”, i.e. the reuse of the same content in different kinds of social software applications. The article concludes with an overview of different applications we envision can be built on top of KiWi. 1 Motivation: From Semantic Wikis to KiWi Semantic Wikis have been under investigation in the research community since 2005 (see e.g. [1,2]). Although there are many different systems with many different properties, a common trait between all Semantic Wikis is that they aim to combine ordinary wiki content and technology with Semantic Web technologies, either in order to provide better wikis (“Semantic Web for Wikis”) or to ease the creation of Semantic Web data (“Wikis for the Semantic Web”) [3]. Many also see Semantic Wikis as the “Semantic Web in a Nutshell”, because – like Wikis show similar traits to the Web as a whole – Semantic Wikis share many properties and also problems with the envisioned Semantic Web. The EU-funded project KiWi (“Knowledge in a Wiki”) takes the Semantic Wiki approach to the next level by providing a platform that allows to build many different kinds of Social Semantic Software, based on the conviction that most social software follows the “Wiki Principles”. By “Wiki Principles”, we mean that the term “Wiki” does not refer to technology alone. It is more a new philosophy of working with Web content influenced by ideas in the OpenSource community. These principles have revolutionised the way we work with content in the (Social) Web: – Wikis allow anyone to edit: The core principle is that there are no access restrictions or strict hierarchies on the content of a wiki. Anyone can easily contribute his or her own knowledge, his or her own ideas, and his or her own content. 1 http://www.kiwi-project.eu – Wikis are easy to use: Anyone who is sufficiently familiar with the basic functionalities of word processing software (write, delete, save) has all the skills required to edit, correct and expand a wiki. – Wiki content is linkable: By allowing users to create links between words and as such between concepts, wikis also allow for the creation of semantic relations, i.e. of meaning. – Wikis support versioning: Never does information disappear on a wiki. If a page is edited, the previous version is still stored somewhere. This has an important psychological effect as it takes away the wiki writer’s block: the fear that something might get lost through editing. – Wikis support all media: Wikis are web-based. So whichever type of content you have, be it text, images, audio, spreadsheets, documents – anything that can be displayed in a web browser can be displayed in a wiki. And even if a file cannot be displayed in the browser itself, it can still be downloaded. This same philosophy is underlying not only Wikis (technically-speaking), but also a large array of other Social Software applications: e.g., a weblog or social networking platform can be seen as just a different user interface (and different way of using), but is otherwise very similar concerning the underlying principles and also technology. In the following, we describe how we realised the KiWi vision in the KiWi System, a generic Semantic Social Software platform based on the Wiki principles. We begin in Section 2 with introducing the concept of what we call “Content Versatility”: content with flexible structures that can be reused in different applications. In Section 3, we then describe KiWi Core Applications: the Wiki, the Dashboard, TagIT, the KiWi Search, and the KiWi Inspector. Section 4 is dedicated to the more technical aspects of the KiWi platform: the system architecture, the data model, the KiWi entity manager, and façading. We conclude this article with an outlook and summary in Section 5. 2 Content Versatility: Same Content, Different Views As we have already outlined in the introduction, what we call the “Wiki Principles” is actually applicable to many Social Software applications. It is therefore close at hand to build generic platforms for developing different kinds of Social Software. And indeed, there are several products already available that aim to deliver a platform that allows to combine wikis, weblogs, social networking, etc. Such platforms are for example Clearspace Community from Jive Software, Community Server from telligent, and Liferay Social Office from Liferay. However, all these systems only provide integration on the user interface level and still see wiki articles, blog posts, etc. as separate kinds of content that is visualised in a specific way. This has a number of serious disadvantages. For 2 http://www.jivesoftware.com/products/clearspace-community 3 http://communityserver.com/ 4 http://www.liferay.com/web/guest/products/social_office instance, something that started as a wiki article can never become a blog post, it will never be possible to attach comments to a wiki article if not foreseen in the data model, and new kinds of content (like our TagIT locations, cf. Section 3.3) cannot be added easily without also doing fundamental changes to the system. KiWi follows a completely different approach which we call “Content Versatility”. The underlying principle is that every piece of information is a combination of human-readable content and associated metadata, and that the same piece of information can be presented to the user in many different forms: as a wiki page, as a blog post, as a comment to a blog, as a photo, or even in a bubble in a map-based application. The decision how the information is displayed is taken based on the metadata of the content, and the context of the content and the user (e.g. metadata, user preferences, different applications). Metadata is represented using RDF and thus does not require a-priori schema definitions, so the data model of the system can be extended even at runtime. In KiWi, we call the smallest piece of information a “content item”. A content item is identified by a URI and consists of human-readable content in the form of XHTML and associated metadata in the form of RDF. The KiWi core system provides means to store, update, search, and query content items, and offers automatic versioning of all updates (content and metadata). Whereas core properties of a content item (like the content, the author, and the creation date) are represented in XML and persisted in a relational database, all other properties can be flexibly defined using RDF properties or relations. The URI of a content item is generated in such a way that it is possible to make a KiWi system part of the Linked Open Data cloud [4]. This allows to easily integrate KiWi content with other services on the Semantic Web. 3 KiWi Core Applications Content Versatility makes it possible to offer completely different views on the content inside the KiWi system without any modifications to the core system or data model. We call such views “KiWi Applications”, and they are one kind of extension offered by the KiWi system (others are currently: KiWi Services, KiWi Widgets, KiWi Actions, and Exporters/Importers). In the following, we describe the set of applications that are part of the KiWi System to illustrate how the Wiki Principles and Content Versatility are realised in KiWi. The applications have been selected based on the requirements identified in the two KiWi use cases and accompanying SNML projects; additional applications are conceivable and reasonable. Additional applications will be offered as separate packages in later stages of the project. KiWi applications share the same context, i.e. when the user browses a content item in the Wiki or Dashboard, she can switch to the TagIT application and view the same content item on a map or to the Inspector and get debugging information on the content item. Fig. 1. The KiWi Wiki: A Semantic Wiki built on top of KiWi